Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/core/src/middleware.ts`:
- Around line 45-55: The redirect branch in middleware.ts drops cookies set
during authentication (from authenticateRequest() / authResult.response), so
when a token is renewed the new Set-Cookie is not forwarded; modify the redirect
handling to detect authResult.response (or any response returned by
authenticateRequest()) and copy its Set-Cookie header(s) into the redirect
response before returning it—e.g., read
authResult.response.headers.getAll('set-cookie') or the single 'set-cookie'
value and append each to the NextResponse.redirect() result (or use
response.cookies.set if available) so the renewed auth cookie is carried over
with the redirect.
- Around line 34-62: Move the authentication call (new
AuthenticationService().authenticateRequest(request)) out of the outer try/catch
so auth errors are not swallowed; if authenticateRequest throws, return a
failing auth response (do not return NextResponse.next()) or let the error
propagate to produce a non-public response. Wrap only the redirect lookup
(redirectsClient.get(path) and subsequent URL/NextResponse.redirect logic) in a
try/catch and on redirect lookup failure fall back to returning
authResult.response; keep references to AuthenticationService,
authenticateRequest, redirectsClient.get, NextResponse.redirect, and
NextResponse.next() to locate the code to change.

In `@packages/core/src/pages/api/fs/auth/login.ts`:
- Around line 43-49: The current login handler treats any non-2xx webopsResponse
as "Invalid password"; update the error handling in the block that checks
webopsResponse (the variable webopsResponse used in the login function) to
inspect webopsResponse.status and only return 401 (or 403 if you prefer) for
explicit auth failures (status === 401 or status === 403) with the existing
invalid-credentials payload, while returning a 503 Service Unavailable (and a
generic upstream error payload) for all other 5xx/non-auth statuses so upstream
outages are not misclassified as bad credentials.
- Around line 53-69: The handler currently echoes the user-supplied returnTo
query into the JSON redirectUrl (variable returnTo) which permits
open-redirects; validate and sanitize returnTo before reflecting it by allowing
only same-site absolute paths (e.g. non-empty string that starts with a single
'/' but not '//' and contains no scheme or host), otherwise fallback to '/';
perform validation where returnTo is computed and use the sanitized value in
response.status(200).json({ redirectUrl: sanitizedReturnTo }), keeping the
existing cookie logic (COOKIE_NAME, TOKEN_TTL_SECONDS,
isSecureAuthCookieForPagesApi, response.setHeader) unchanged.

In `@packages/core/src/pages/fs-auth-login/index.tsx`:
- Around line 1-3: The login page must be marked non-indexable by search
engines; update the FS auth page component in this file to include a robots meta
tag. Import Head from 'next/head' and add <meta name="robots"
content="noindex,nofollow" /> inside the page component's returned JSX (the
default exported component in this module that renders the Button/InputField
form), ensuring the meta tag appears alongside other head elements so crawlers
see it for this public route.

In `@packages/core/src/server/authentication-service.ts`:
- Around line 94-97: The code currently treats a valid token with
verification.payload.protected === false as a long-lived negative cache and
immediately returns NextResponse.next(), which allows visitors to bypass
newly-enabled protection for TOKEN_TTL_SECONDS; modify the logic in
authentication-service.ts (the block handling verification.valid &&
verification.payload) to recheck current protection state instead of trusting a
false protected flag—call the same protection-check routine used for new
requests (or fetch latest merchant protection setting) and only return
NextResponse.next() when both the token is valid and the current protection is
disabled, otherwise proceed to enforce protection (e.g., clear the cookie or
redirect to login). Ensure references to verification.payload.protected,
TOKEN_TTL_SECONDS, and the NextResponse.next() return path are updated
accordingly.
- Around line 114-127: Normalize the Host header before checking for the default
domain: in shouldCheckProtection(request: NextRequest) (and likewise in
shouldProtectDomain(request: NextRequest)) read request.headers.get('host') into
a variable, lower-case it and strip any port portion (e.g.
host.split(':')[0].trim().toLowerCase()), then use that
normalizedHost.endsWith('.vtex.app') instead of the raw header; update both
methods to use the same normalization logic to ensure hosts like
"preview.vtex.app:443" or mixed-case values are handled correctly.
- Around line 268-270: The redirectToLogin method currently sets returnTo to
only request.nextUrl.pathname, losing query parameters; update redirectToLogin
(the method named redirectToLogin in authentication-service.ts) to include the
full path+query by appending request.nextUrl.search (e.g., use
request.nextUrl.pathname + request.nextUrl.search or otherwise serialize the
original nextUrl) when setting loginUrl.searchParams.set('returnTo', ...), so
requests like /search?term=chair&page=2 preserve their query string through the
/fs-auth-login redirect.

In `@packages/core/src/server/password-protection/auth-cookie.ts`:
- Around line 4-9: The isLocalHost function misparses bracketed IPv6 addresses
like "[::1]:3000" because splitting on ':' yields '['; update isLocalHost to
detect and handle bracketed IPv6 first: if host starts with '[' extract the
substring between '[' and ']' as the hostname, otherwise split on ':' and take
the first segment; normalize to lower-case and then check against 'localhost',
'127.0.0.1', '::1' and '[::1]' (or simply strip brackets before comparison) so
IPv6 loopback is correctly recognized and Secure cookies are disabled on
localhost IPv6.

In `@packages/core/src/server/password-protection/webops-api.ts`:
- Around line 16-19: The protectionStatusUrl is built by interpolating
discoveryConfig.api.storeId into the query string which can break for reserved
characters; update the construction of protectionStatusUrl to create the base
URL with origin and pathname, then set the storeId using URL.searchParams (e.g.,
call protectionStatusUrl.searchParams.set('storeId',
discoveryConfig.api.storeId)) so the storeId is properly URL-encoded; locate the
symbol protectionStatusUrl and the referenced discoveryConfig.api.storeId and
replace the current template-string-based URL construction with creation +
searchParams.set.
- Around line 5-9: The code currently assigns origin using the
nullish-coalescing operator which lets an all-whitespace WEBOPS_API_URL become
an empty string and produce an invalid URL; update the logic that computes
origin (the variable named origin and the env var WEBOPS_API_URL) to treat a
trimmed empty string as unset by checking for a non-empty trimmed value (e.g.,
compute a trimmed value into a temp like raw =
process.env.WEBOPS_API_URL?.trim().replaceAll(/\/+$/g, '') and then use origin =
raw && raw.length ? raw : DEFAULT_WEBOPS_ORIGIN) and keep the existing
origin.startsWith('http') normalization to prepend https:// when needed.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/core/src/server/authentication-service.ts`:
- Around line 84-87: getNormalizedHost currently splits the host on ':' which
breaks for bracketed IPv6 like "[::1]:8080"; update
getNormalizedHost(NextRequest) to handle bracketed IPv6 by detecting if hostname
startsWith('[') and, in that case, extract the text between the first '[' and
the matching ']' (dropping any trailing :port), otherwise strip the port by
cutting at the last ':' (use lastIndexOf) to avoid splitting hostnames with
colons; then trim and toLowerCase the result so downstream checks (e.g.,
endsWith('.vtex.app')) work correctly.

---

Nitpick comments:
In `@packages/core/src/server/authentication-service.ts`:
- Around line 96-114: In verifyToken handling inside the authentication flow,
collapse the nested valid-token branches: when verification.valid &&
verification.payload is true, immediately return NextResponse.next() instead of
checking verification.payload.protected and shouldProtectDomain(request,
verification.payload.scope) since all three branches currently return the same
value; remove the dead conditionals in the valid branch in
authentication-service.ts (around the verifyToken usage) so the code reads an
early return, and keep the expired-path logic that calls
tryRenewSession(request, token, verification.payload) intact.
- Around line 161-188: The code currently coerces untrusted JWT payloads with
"as unknown as TokenPayload"; add a runtime validator (e.g.,
toTokenPayload(payload: JWTPayload): TokenPayload | null) that checks typeof
payload.storeId === 'string', typeof payload.protected === 'boolean', and
payload.scope is undefined or a string, then use that validator in both the
jwtVerify success path and the decodeJwt expired path (replace the double casts)
and return failure (valid: false) when the validator returns null; reference
jwtVerify, decodeJwt, isJwtExpiredError, and payloadMatchesStore to locate where
to plug the validator and to keep the existing store-matching logic.